手机取代扫码枪接ERP？一位集成商老兵的微服务落地复盘
去年秋天，我们团队接了个挺有意思的活儿。一家区域性生鲜连锁客户找上门，说他们仓库里那批工业扫码枪老化严重，采购新枪和维修的费用年年涨，想让我们试试能不能用商场员工自己的手机，跑个微信小程序，直接扫商品码入库出库，然后实时对接他们那套基于老牌.NET框架的ERP系统。
作为做了十几年系统集成的老油条，我一开始是拒绝的。工业扫码枪和手机摄像头根本不是一个量级，尤其是在冷链仓库那种雾气弥漫、条码脏污的环境下。但客户坚持要验证可行性，预算也给得痛快，我们就组了个四人小组，用微服务思路做了一套验证系统，跑下来效果居然不错。今天趁热打铁，聊聊我们在手机代替扫码枪、小程序对接ERP这块的微服务设计经验，算是给同行抛块砖。
先说整体架构。客户原有ERP是单体应用，对外只留了几个陈旧的WebService接口，吞吐卡在每秒二十来笔就不行了。如果我们让小程序直接调ERP，高峰盘点时几百个店员同时扫，系统分分钟瘫痪。所以我们坚决上了微服务，依托Spring Cloud Alibaba栈，把系统按业务域拆成了四个核心服务：终端鉴权服务、条码解析与增强服务、ERP协议适配服务、以及异步消息缓冲服务。
这里有个坑得提一下。很多人以为微信小程序自带扫码能力就万事大吉，但我们实测发现，客户用的一种自定义长度的后缀码，微信原生扫码对这类码识别率仅五成多，而且扫出来偶尔丢字符。我们在后端单独写了个“条码解析微服务”，不依赖微信的结果，而是让小程序把原始图片流加密传到后台，用Zxing结合自研的纠错算法重新解。这个服务无状态，挂了不影响登录和其他业务，横向扩展也简单。压测时单机带AES加解密和图像解析，稳定跑在800 QPS以上，端到端从拍摄到返回解析结果控制在150毫秒内。
对接ERP才是最头疼的。那套老ERP数据库用了存储过程锁表更新库存，并发一高就死锁。我们设计ERP适配服务时，压根没用同步直调。所有扫码后的业务事件（如“入库单：商品A，数量10”）先扔进RabbitMQ，适配服务以受限并发消费者匀速消费，把消息翻译成ERP能懂的SOAP报文，再慢悠悠喂给老系统。为了防丢数据，我们用了本地消息表加定时对账补偿，哪怕ERP半夜宕机，早上恢复后也能把队列里的单子补完。这种削峰填谷的写法，让老ERP安稳度过了双十二盘点高峰，没出过一例错账。
另外，小程序跟我们微服务网关之间，我们没走小程序云开发，而是自建了HTTPS网关，集成Sentinel做细粒度限流。比如鉴权服务限流稍宽，条码解析服务按图像解析资源限量，避免某人狂扫把计算资源占满。实际部署后，从手机按键到ERP库存变更，平均延迟控制在280毫秒左右，店员体感几乎是实时的。
不过说实话，手机替代扫码枪这事不能一刀切。我们在项目里明确告诉客户：高密度流水线作业、或者冷库结霜严重的工位，还是得留几把工业枪；但日常门店收货、周期盘点、移动巡检，手机小程序完全胜任，一年帮他们省了小十万硬件费。
微服务划分也别迷信“越小越好”。最初我们曾想把扫码和OCR拆成两个服务，后来发现网络跳转开销比计算还大，就合并了。边界得跟着业务波动走，这是实战教给我们的。
以上就是我们这次集成项目的一点真实记录。架构没有银弹，能稳妥帮客户省钱、避开坑的方案就是好方案。有兴趣的同行可以交流，下次或许聊聊我们怎么用边缘计算进一步压低扫码延迟。
微信号：18581869297
